<div class="container" id="container">
  <div class="page article js_show">
    <div class="page__hd">
      <h1 class="page__title">何时需要重构</h1>
      <p class="page__desc">现在也可以，最好是昨天</p>
    </div>
    <div class="page__bd">
      <article class="weui-article">
        <h1></h1>
        <section>
          <h2 class="title"></h2>
          <section>
            <h3>什么是重构</h3>
            <p>
              我们在一层一层往上建造通天塔的时候，我们可能通过不断实践，发现之前的做法有值得改进的地方，也可能发现之前规划的结构有不再适合的地方。
              在楼层数增大和人员规模扩大的情况，这些实践中的经验和改进对于更快更好的建造是有正面意义的，然而我们如何去处理我们已经建造好的那些部分呢？
              拆掉重建，一切归零，从头再来？
              还是对之前的部分采用新的部分进行适当优化改造？
            </p>
            <p>
              <h4>重构基于对过去所实现价值的有条件的肯定和继承。</h4>
              重构不是伤筋动骨地彻底重写，小步前进逐步优化，往往可以得到与推翻重来相同甚至更好的结果。
              当我们的系统在不断使用过程中，会有很多不同的新需求加入，我们往往在完成需求的同时增加入新的问题，或则增加新功能本身就要求
              去修改之前的代码。
              一个系统要保持生命力，不被替换和陷入bug泥团中，我们需要持续不断重构我们之前所写的代码，或则别人留下来的代码。
              重构的目标是让代码更加清晰可读，让每个对系统的代码理解可以被分享和继承。
              持续不断的重构在于让软件变得更可以被人理解，更方便扩展和维护，更容易复用。
            </p>
            <p>
              <h4>重构并非推倒重来，重构的目标在渐进性的改革措施。</h4>
              即使是一行注释也是对系统重构的贡献，我们需要保留和分享。
              技术是用来服务的，已经存在的业务系统中不仅仅是技术的简单组合，同时包括业务逻辑和产品说明，在对新技术和业务系统尚不能有完整的认识掌控的情况下
              贸然进行大型业务系统的重构往往会导致严重后果。
            </p>
          </section>

          <section>
            <h3>重构的目标</h3>
            <p>
              <h4>提高代码可读性</h4>
              <p>
                重构的目标是让代码更加清晰可读，让每个对系统的代码理解可以被分享和继承。即使是一行注释也是对系统的贡献，我们需要保留和分享。
                持续不断的重构在于让软件变得更可以被人理解，更方便扩展和维护，更容易复用。
              </p>
              <h4>提高系统鲁棒性</h4>
              <p>
                上医治未病。即使代码还能正常运行的时候，重构也是很有价值的。定位问题之所以困难，往往因为你无法厘清到底是技术本身的问题，还是业务系统的改变导致的问题。
                当一个系统不断被维护的时候就会加入很多变化，这些变化就是新的出错点，只有不断重构优化这些新的变化点，才能迅速定位问题的所在。
              </p>
              <h4>提高系统的可用性</h4>
              <p>
                皮之不存，毛将焉附。如果底层架构实现不断发生剧烈变化，可用性自然无从谈起。有步骤的系统重构可以在不影响已有功能的前提下，逐步优化系统，提高
                系统的可用性。
              </p>
            </p>
          </section>

          <section>
            <h3>什么时候应该重构</h3>
            <p>
              <h4>
                如同测试和管理对于系统构建的影像，代码重构需要贯穿于整个系统的生命周期。
              </h4>
              从系统上线那一刻起，重构就需要被持续不断地进行。
              重构如同清洁工所做的事情，及时发现发现街道上的灰尘和落叶，及时进行清理并思考如何避免类似的问题再次发生。
              瞻前顾后，当我们发现代码中存在的问题的时候，要思考以后如何避免此类问题，是否该功能足够普遍，值得为此提供通用的方法？目前代码中，还有哪些地方可能
              存在类似问题，是否需要现在一并改掉？如果目前没有精力全部改掉，可以加上特殊标记，待日后统一修改。
            </p>
            <p>
              “菩提本无树，明镜已非台，本来无一物，何处惹尘埃”。重构要成为一种习惯，重构是个需要贯穿整个项目始末的一件事情，我们添加新功能的时候需要，我们在排查问题的时候需要，
              我们在修复已知问题的时候需要，我们在code review的时候需要，我们清闲的时候也需要。
            </p>
            <p>
            </p>
          </section>
          <section>
            <h3>什么时候不适合重构</h3>
            <p>
              <h4>在项目上线的初期，或则已经进入业务验证阶段正准备上线。</h4>
              重构也只是项目管理中的一环，项目中的任何改动对项目都是有影像的，因此在肯定重构工作应该贯穿始末的同时，要考虑项目目前所处的阶段。
              大规模的重构会引入一些新的bug，使得测试人员和项目管理人员
              对项目的进度和质量产生怀疑，对程序员所做的重构工作的价值进行质疑，进而对重构可能引起的不可控的局面产生担忧，
              这些质疑和担忧将反过来影像重构工作的开展，因此可以认为这些阶段的重构工作应该相对谨慎。
            </p>
            <p>
              <h4>在没有完整的产品文档说明</h4>
              一个复杂系统进行重构的时候，我们往往会发现很多原来系统的不足，然而当我们没有一个对于产品的完整清晰的描述的情况下，我们看能会
              出现两种情况：继续使用老的代码逻辑；按照正确的方式重新实现逻辑。原封不动实现老的逻辑将使得旧系统失去修正一个错误的机会，这个错误
              将会继续引入到新系统中，而抛弃原来的逻辑重新实现的话则可能是极其危险的，因为我们可能丢掉了一些非常重要的限制条件，以至于上线的时候产生
              生产事故。重构的方式必须基于目前系统所遇到的问题，如何解决这些问题为出发点，否则可能在做重复的工作，之前遇到的问题仍然得不到解决
              ，抑或之前的问题解决了，又出现了新的问题
            </p>
            <p>
              <h4>系统本身已经没有维护价值</h4>
              什么时候这个系统已经无法进行维护了，必须要进行推倒重来呢？
              我们一再强调，不要被新的技术框架的理念所吸引，新框架的技术的流行是有盲目性的，
              很多短期内行之有效的快捷构建原型的方式往往在系统规模不断增加的情况下难以为继。
              重构并不是将系统彻底推翻重新开发，推翻之前的所有设计进行重新开发是一个浩大的工程，我们必须保持审慎的态度，我们在这里企图对"推翻重写"的合理性进行分析。
              就目前手头的系统来讲，之前的系统是由外包人员开发，外包人员几乎全部离职，没有人来维护旧系统；旧系统是前后端不分离的开发方式，无法让专业前端参与其中
              旧系统使用了，自动生成的方式开发页面，根本无法进行二次开发。
              如果以上情况符合，是否重构确实值得进一步评估。
            </p>
          </section>

        </section>
      </article>
    </div>
    <div class="page__ft" style='display:none'>
      <a href="javascript:home()"><img src="./images/icon_footer_link.png"></a>
    </div>
  </div></div>
